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An Integrated j^pcessor is provided wherein . 



- .-r.-v.- ^.-^s,-:, is te$ 

-:e^isiU^rvi^J^tTi^^^itfc : Ss — *rx*£/«*r-;.- " 1 — 



a common semiconductor die and are linked by 
a common local bus. A testing circuit, also 
situated on the die and coupled to the common 

iyfty A tast^c^mand, ^gjgnjfe . ^ \ 



„ naily . originate^ CQhTfr^^ 

^eoxtpuiec^ 

i-one^S^^ 

* Incorporated on the motherboard of a target 
computer which is linked by a JTAG or other 
testing protocol bus to a host computer. The 
host computer generates the test command 
signals which are sent to and received by the 
testing circuit in the integrated processor. A 
debug memory space is reserved in the main 
system memory of the target computer for stor- 
age of debug software which is downloaded 

— £om_ the host computer. The debug software 
thus stored is executed when the processor on 
the target computer enters a debug mode. 
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Thjs invention relates in^general to microprocessors. and, more particularly, to a type of microprocessor 
referred to as an. "integrated rnjcroprocesspr"._ An,"integrated microprocessor" is a microprocessor in which an 
othetme^sbarj^lcine: microprocessor layout is integrated with other functional units*on a common semicon- 
ductor die. ' 

Ov«&iyear8£^ theyhave-progressedfrom early - - 

8 bit implementations through later 16 bit 32 bit and: 64 bit implementations. At the same time that the data 
bandwidth of microprocessors has increased, the amount of functionality provided on a single semiconductor 
die has also substantially increased. For example, whereas the standalone Intel 386 microprocessor includes 
mainly a CPU and a memory management unit (MMU), in comparison the standalone Intel 486 microprocessor 
^Jnciudea aCPU .afloat managemeefcunit (MMU>tf tlocstwtto^ 

^:6h~tfie same semiconductor dK^ .'„!.' .. .„-"7" : "\ S.---'^ . ■ _ .^i^..^ -i. r V." 

It desirable to integrate thert units as the inters -.- - . 

Vupt controller, direct memory access (DMA) circuitry andmemory" controller aif bn the same semiconductor 
die together with the standalone microprocessor design layout. Microprocessors with such a very high degree 
^efftmctfbha^ 

words, "integrated processors" are those processors which include a standalone microprocessor layout and, 
\ one or rrwefundi^ -■ ■ " " . . 

Integrated processors present increased challenges to the microprocessor designer in terms of functional 
testability. In the case of older microprocessors, functional units such as DMA, the interrupt controller, the FPU, 
-~ ana others were located on a separately packaged chip or discrete circuitry separate from the microprocessor. 
^ "fife th'oser ciase's; the functionarunit" was readily accessible for testing. However, when tfiese f unctionaf untts-- - — - 

are integrated on a common semiconductor die in an "integrated processor", they are much less accessible to 
, those invoteednrt device and systen^tesfcing^--— — 



25 



It will-be- assumed that the integrated processor is intended for use as^part of a larger funtfibrrarstructure- ~^ 
such as a personal computer, workstation or other computing device. For convenience, the board oawhich^ - 
the integrated processor is located will be called the motherboard, as is common practice-. ~The^processoris^ ?r *^ 
typically &lug^diD^ajrf^cat^j 



In the case of the "in-circuit" emulator, jnstead of plugging ta^pr^e^orjr^^ 



Moreover, such "in-circuit" emulators often only fit pre-production models of a personal computer and not the 
final production model. Another disadvantage of such ■"iftcir^^ 
that they are ten, not ayaUafie i nihe_ ear I y. part of th^on^^^ 



Boundar y ooorv to a no ther app r o a ch w ftfc rvpemt^^ 

^b^iEEEStanda^;! 

ifd^oflri 



JvfofB gart^ adjacent each component pin of the device under test. 

Wthferrie using scan testing techni- 
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ques. A test vector is supplied to the boundary scan registers and the resultant output is compared with the 
expeetedetrt|»ifrEiTOre^ of some of the components of the device may be determined in this ~ 

manner. The protocol by which the tester communicates with the boundary scan registers is referred to as the 
JTAG (Joint Test Action Group) protocol. The IEEE 1149.1 standard defines a non-proprietary JTAG interface 
through which test signals using this testing protocol are transmitted. 



H^rnSfrBSS^^ 

so-- devices-such as'frrtegrated processors 11 , Another disadvantage of boundary scan testing Is that it often does 
not provide full test information on all components of a device under test. 

Testing or debugging of a microprocessor system, for example a personal computer using a microproces- 
sor, can take many forms and can be viewed at many.different stages of development For instance, debugging 
of such a microprocessor system occurs prior to executing BIGS (before th^v^^j»boefeifcHfe)^ durln^BIOS:^ 

55 power on self test (but with ho operating system loaded), after the operating system is loaded (but with no ap- 
plication software loaded), and after application software is Ioadedr (BfOS : refers to the Basic Input Output 
System of a microprocessor system;} Debugging- and testing of the integrated processor is desirable at all of 
these stages: — ~ * - — - *- ----- ^-.~~ T — — -.- • 
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One conventional debugging approach is to load debugging software on the same microprocessor system 
which is being debugged. This approach assumes that the microprocessor system is in bootable condition 
which may not be the case in early system development Anotherdrawback with this approach is that the de- 
bugging software may have a resource conflict with the application software which the microprocessor system 
5 T -j.-jB-runni'ng: In this sftifefroitrtKi^ arid the application software demand access to the 
same resource (memory, disk drive, etc.) at the same time. This problem can lead to system crashes and hin- 
ders the debugging and application testing process. 

We will describe a debugging tool which is capable of testing the components of an integrated micropro- 
cessor under varied operating conditions. 
- ^J3l- — _ _ will describe a debugging tool which is capable of testing the CPU and functional units of an integrated 
processor atthe ymcm" stages- of microprocessor system development, that is, from prior to achievement of 
system (footing all the way through operating system load and application software development. 

We will describe a debugging toot which operates at relatively high speed while testing an integrated proc- 
essor. 

1 & , - We will describe e debugging tool for integrated processors which does not require a special custom-made 
connector or test rig for each integrated processor designed. 

We will describe a debug^^ avoids resource conflicts during debugging of application soft- 

ware. 

In accordance with one embodiment of the present invention, a microprocessor with built-in testing capa- 
20 bility is provided. More particularly, the disclosed microprocessor includes a semiconductor die and a central 
processing unit situated on the die. The microprocessor also includes a local bus which is situated on the die 
and coupled to the central processing unit. The microprocessor further includes at least one functional unit 
situated on the die and coupled to the locat bus. A testing circuit is situated on the die and is coupled to the 
local bus. The testing circuit initiates a bus cycle for testing purposes in response to a test command originating 
25 external to the microprocessor. 



BRIEF DESCWPTiON OF THE DRAWINGS 



The features of the invention believed to be novel are specifically set forth in the appended claims. How- 



hod of operation. mavD€ 



FIG. 1 is a block diagram of an integrated microprocessor including a hardware/software debugging tool. 
FIG. 2 is a block diagram of a target computer system employing the integrated microprocessor of FIG. 1 
shown together with a host computer. 

-tool 
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ffiaretrfffe emp^yitfby the hard- 



FTCJ^TTs a memory map of the memory space employed by the hardware/software debugging tool. 
FIG. 8 is a block diagram of the arbitration portion of the integrated processor. 
FIG. 9A-9B are flowcharts which together depict the operational flow of the debugging tool of the present 
invention. 

FIG. 10 is a representation of the pin-out of the debugging tool of the invention. 
FIG. 11A is a timing diagram depicting a memory read cycle in normal mode. 
FIG. 11 B is a timing diagram depicting an I/O read cycle in normal mode. 
FIG. 11C is a timing diagram depicting a memory write cycle in normal mode. 
~~ ~FfG";fio r i s a timing diagram depicting a memory write cycle in system debug mode. 

FIG. 11E is a timing diagram depicting a memory write cycle in system management mode (SMM). 



I. Operational Environment 



FIG. 1 is a block diagram of an integrated microprocessor 10 in which the hardware/software debugging 
55 tool (HDT) 15 of the present invention is employed. Integrated processor 1 0 includes a standalone central proc- 
essing unit (CPU) 20 which is situated on semiconductor die 25. The term "standalone" is used here to indicate 
that the layout from a standalone CPU such as an Advanced Micro Devices, Inc. Am386 or Am486 micropro- 
cessor, for example, is fabricated on semiconductor die 25. Whereas such microprocessor devices are normally 
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used in standalone fashion surrounded by various support chips, in the present invention the layout from such 
a standalone microprocessor is incorporated on die 25 along with HDT 15 and other structures. 

As seen in FIG..1, a local bus 30 couples CPU 20 to HDT 15. Other functional units which normally reside 
in standalone chips separate from the CPU, such as memory controller 35. direct memory access (DMA) con- 
. ^^^^-^„^^ and. bus interface-unit 50, are also coupied to local bus 30 on die 25. A frocal 

bus port 30A is provided for interfacing external devices to local bus 30. 

An expansion bus port 50A is provided to bus interface unit 50 for connecting external input/output (I/O) 
devices to microprocessor 10 via an expansion I/O bus 55. la one embodiment, expansion bus 55 is a PCI 
(Peripheral Component Interconnect) bus as set forth in the PCI Special Interest Group specification for that 
.^..^-^^^ an^^ bus, an Extended industry. ^ 

". " " . '-" Standard Archte 

purposes ofthis document, a peripheral device" is defined as/a functidnalunit which.is~. 
- located external to the microprocessor. - - -- - 

.. A memory port 35A is provided to memory controller 35 to permit memory such as dynamic random access 
~-^*T^i3£^ (EPROM) to be coupled to memory controller 

35. As indicated by the functional unit designated "other functional unit" 60. other functional units not listed 

""" *'"*' ~;abWe^burd^ -■ - - 

As seen in FIG. 1, HDT 15 includes a JTAG interface (or JTAG port) 15Afor coupling HDT 15 to a host 
unit 200 over a JTAG bus. The JTAG interface is defined by IEEE Standard 1149.1. 
" : - ie " : ' in actual practice as shown in FIG. 2, microprocessor 10 is situated on a motherboard 100 which is also 

... referred to as target system TOO.TarfefSysteM^ witJva hosf system 200 during 9ys*em<*est* 

ing. Target system 100 includes a disk controller 105 and a video controller 110 coupled to local bus 30 via 

local bus port 30A, A modem^^^ 

expansion bus 55. Arandom access memory 125, such as a DRAM memory for example, is coupled to memory 1 
25 controller port 35A as shown. 

Target system 1 00 is the system for which testing and debugging is desired at the multiple stages of system' 
development To„acccrop]ishthjs testing 

test commands can be sent from host 200 to the integrated processor 1 Oofterget system 1 1 00 to jgxer cjse and^ 



onto which debugging sof tware can be loaded. It should be noted that the target system 100 under test is sep- 
arate and distinct from the host systern 200 which will initiate and control the testing of target system 100. . 



" _ - A sii^f|ed-bk)dc^iag 3, bus widths are indicated by a hash 

form We^TAGT5drT^ 

-^^s^ (including commands, 
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-^StKI^ 200. The TiyiS input is a control input which i.jnj^ms^ 

2 4feT 15 fi^^ StandardTest A(xess P * ; r ~ 

chitecture, IEEE Std. 1149.1-1990, which is incorporated herein by reference. The TCK input of HDT 15 is the 
JTAG clock input through which a clocking signal is provided to HDT 15 by host system 200. TheTDO outpur- - - 
of HDT 15 is the JTAG data output through which responsive test data, results and status information are sent 
from HDT 15 back to host system 200. The protocol of the signals on the TDI, TMS, TCK and TDO lines are 
all defined in the above-cited IEEE 1149.1 standard. 

The TDI and TCK Inputs of HOT TSare coupledJo the inputc* a shjftj;egis£er 300 which include&an OP-„ „ . 

)E portionT6S, aB'E/ttD portion 307 and an ADDR /DATA portion 310. In one embodiment of the invention, 
shift register 300 is 50 bits wide to accommodate a 50 bit wide command from host 200. This bit width is al- 
located as follows: 4 bits to the opcode, 6 bits to the BE/MD information, 32 bits to the address or data, and 
8 bits to guard bits for the command. 

Shift register 300 is a serial in/parallel out - parallel in/serial out shift register. When a command is shifted 
into shift register 300 serially torn theJTAG i TDj^jta input lin^, the ppcode PPItjon_ ^1^^^!^^^^^^ ^. 
"ifftfie* o^cod¥"p^o^rv305'1oftegister 300^ ff^c^ocfeus^ 355'via a 4 bit 

wide parallel output of opcode portio n 305 as show n. Control circuit 355causes the appropriate bus cycle sig- 
nals to be generated onTc^. biis^O so that the particular operation' specified in the command's opcode is 
performed. More specif ically, control circuit 355 issues the appropriate control signals on local control bus 360 
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which is part of local bus 30 as seen in FIG. 3. In this manner, the specified bus cycle is generated. 

The address or data information from the command is forwarded from ADDR/DATA portion 31 0 to address 
bus 340 and data bus 330 t respectively. The bus cycle specified is carried out and the result is returned over 
local bus 30 back to ADDR/DATA portion 31 0. The result in ADDR/DATA portion 310 is forwarded back to host 
209 over JTAG bus 205. r- * . . . ... 

To summarize, the opcode received by OPCODE portion 305 defines the task to be performed by HDT 
1 5. The output of shift register 300 is the TDO data output of HDT 1 5 at which results or responses to the com- 
mands are sent via JTAG bus 205 back to the host 200. The BE/MD portion 307 serves as a placeholder for 
Byte Enable (BE) and Mode (MD) information associated with a particular command. The ADDR/DATA portion 
3 to hqjds the Address (ADOR).pr Data (DATA) information of a received command as it is shifted into shift 
register 300 from the TDt data input line. The ADDR/DATA portion 310 also stores the result of the command 
"as it comes back over local bus 30. After the result information is received back in ADDR/DATA portion 310, 
it is shifted out the TDO data output line back to the host via JTAG bus 205. 



IH. Hardware/Software Test Tool - Detailed Operation BUILT-IN COMMANDS; CONTROL COMMANDS 



Shift register 30Q.ts coined tD.a*data^out" register 315; to control register 320 and to address register 
325 as shown in FIG. 3. The output of data-out register 31 5 is coupled to a data bus 330 (D31 :D0) within local 
bus 30. The output of control register 320 is coupled to system control bus 22 which communicates system 
20 control information between CPU 20 and HDT 1 5. The output of address register 325 is coupled to an address 
bus 340 within local bus 30. 

HDT 15 includes a "data-in" register 345 which is coupled between the data bus 330 of local bus 30 and 
- one input of a two input multiplexer (MUX) 350. Data-in register 345 receives result data back from the local 
bus in response to commands and provides that result data to multiplexer 350. The second input of multiplexer 
25 3 50 is coupled to the system control bus 22. More specifically, the output of control register 320 is coupled to 
the second input of multiplexer 350 such that the control bits stored in control register are provided to multi- 
plexer 350. In this manner, either input data from local data bus 330 or a snapshot of cur rent system c ontrol 



output of MUX 350 is coupled to the ADDR/DATA portion 310 of shift register 300. The informatio n st ored in 



While many different commands can be provided to HDT 1 5 to cause different local bus cycles and other 
system level functions to be performed, such as writing and reading particular memory locations, a simplified 
illustrative example is now discussed wherein the host 200 issues a command for a read cycle. The read com- 

TCb'mms 



te^htfted into shift-register 300-bit by^afra^^detetrro signaKTCK. 

ecs^plrl^ 310 to control the transfer of input in- 

FBlSrgW; ' TOFdbntroller 352 is of the type specified by the 
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____ S^^^^S^^^mS^mtr^md Boundary-Scan Architecture, IEEE Std. 1149.1-1990. More par- 

^^T^^gontroller 352 is a synchronous finite state machine which responds to changes in the TMS and 
^ — 32 ?W^^S"offf^J7AT& bus. The TMS (test mode select) input to TAP controller 352 receives a TMS signal 
which is decoded by TAP controller 352 to control test operations. The state diagram for TAP controller 352 
as per IEEE Std. 1149.1 is shown in FIG. 4. In FIG. 4, the value shown next to each state transition represents 
the signal present at the TMS pin at the time of a rising edge of clock TCK. More information with respect to 
TAP controller 352 is found in Chapter 5 of IEEE Std. 1149.1. The state diagram shown shown in FIG. 4 is also 
referred to as the JTAG state machine. 

When the opcode portion and address portion of the command, together with the BE/MD portion, have 
been fully docked into shift register 300, a Load Shift Register signal is generated and the opcode portion or 
opcode of the command is provided to timing and control circuit 355. Data, namely commands, are written from 
host 200 to HDT 1 5 while HDT 1 5 is in an "Update-DR* state under the control of TAP controller 352, and return 
data are written back to host 200 in a "Capture DR" state both under the control of TAP controller 352 as per 
the cited IEEE Std. 1149.1-1990 specification and as seen in the state diagram of FIG.4. Read data are cap- 
tured during the "Capture_DR" state and shifted out during the "Shift-DR" state. Write data are shifted in during 
the n Shift-DR° state and written during the 'Update-DR" state. 

As shown in FIG. 5, control circuit 355 includes an opcode decoder 357 which decodes the particular op- 
code (in this example, a read opcode) provided by opcode portion 305. The LOAD SHIFT REGISTER signal 
from TAP controller 352 informs opcode decoder 357 of the fact that a new command including opcode, BE/MD 
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and ADDR/DATA portions has been fully shifted into shift register 300 and is ready for processing. 

Opcode decoder 357 Is coupled to shift register opcode portion 305 (see FIG. 3) to receive the opcode of 

: j™- . eachxcfwrwr^ 200 via the JTAG bus 205. Each command includes an opcode field, 

a BE/MD field and an ADDR/DATA field. Opcode decoder 357 decodes the particular opcode (opcode field) 

i-.-r .jfe, 5 s zoTritf. tesuatfi ti^^^^X^ivg^i over ty pe bus 353 tea bus cycle state machine 358. Opcotfe decoder 357 ' " 
assigns values to the Bus Cycle Type signal according to the particular type of opcode loaded in shift register 
300. In one embodiment, type bus 353 is 3 bits wide and is capable of specifying 8 different types of com- 
mands. 

In one example, if the opcode corresponding to a read memory bus cycle is received by opcode decoder 

type .gtpuicft buscyci&state tnacfcme 
. 1 " j; \ "358. |f the opcode corTespdndjrig to an ifcread bcrs.cycte ^liVecerved by opcodedaeqder 3K v tjw§.decpder - ; }2 
?A7/ send V^ ....... — ^^^^^.^^^^^^ 

Several typical commands which are transmitted to HOT 15 for decoding and processing are listed below 
in TABLE 1. The following commands correspond to the different types of bus cycles or activities which can 

r fhttfSffi^fbf^ present Invention; These commands are aflsmatTve 

referred to as built-in commands. 



TABLE 1 



20 



25 



Command Format 



001000 0000 [Null] 
00 1100 0000 [Null] 



Select Control Register 
Select Data Register 




10 00MD -BE* {Addr} ^ : 
10 01MD -BE^ [A<Wrl^ 




Generate Interrupt Acknowledge Cycte- 
GenffafiT I/O Wn^Cydfe 




llMt&:&&i/ ! ^ Memory Da$&4Mrite £ye*es 



The Byte Enable (BE) field of the command format indicates the particular bytes to be written or read for the 
45 particular accessed word. On writes, the selected bytes are written. On reads, the memory controller ignores 
the byte enable and reads all bytes of the word. An example of a special cycle listed in Table 1 is the conventional 

halt^de.^ h ^ b y t» -enetofee-and^Kidfes» (A1 , AO) contain one of the legal combinations in Table 2 below: In 

Table 2; A1 aihd^ of the address referenced in the read or write. 
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Table 2 



..-5 


BYTE ENABLE (BE) FIELD OF THE BUILT-IN COMMAND 


Byte Enable 


Address (A1.A0) 


Cycle Type. 




1110 


00 


One byte at address 00 




1100 


00 


Two bytes at address 00 


*0 


1000 . . 


00 . 


Three bytes at address 00 


■ ■ -~ - - - 


oooa 


00 


Four bytes at address 00 




1101 


01 


One byte at address 01 




-1001 


01 - 


Two bytes at address 01 




0001 


01 


Three bytes at address 01 




1011 


10 


One byte at address 10 


20 


0011 


10 


Two bytes at address 10 




0111 


11 


One byte at address 11 



25 



On special bus cycles, the byte enables (BE's) identify the type of cycle being performed as per Table 3 below: 

Table 3 



BE(3:0) 



1101 
1011. 



Special Cycle Type 



Shutdown ; 
Cache Flush 
Halt , _ :: 



Byte Lane For Other Cycles 



Data(07:6or 
Data (15:08) 
Data (23:1 6) 




space to be employed for a particular memory read 
accesses the MD field is a don't care.) More particularly, 
space employed is normal memory, system management mode 



Table 4 



45 


MODE (MD) FIELD OF THE BUILT-IN COMMAND 


MD 


Address Space 




00 


Normal Memory 


50 


01 


System Management Mode (SMM) 




10 


System Debug Mode 




11 


Illegal 



55 



It is noted that the commands of Table 1 are "built-in commands" in that they are hard-coded into state 
machine 358. These commands can advantageously be executed without the involvement of the CPU. In other 
words, bus cycles and I/O activities can be performed without CPU involvement More particularly, main mem- 
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ory reads and writes as well as I/O reads and writes are desirably performed for testing purposes without CPU 
involvement. For this reason. HOT 15 is particularly effective in debugging partially operational computer sys- 
tems <^puter systems in the earlyjitages of system development. 

In. actual practice, a read local bus cycle is implemented in the following fashion. The read data local bus 
& i-c_cyde i& inifrated ^'{£ereifeqg-a sequence oftwa commands to HOT 15 for decoding by opcode decoder 357 
and processing by state machine 358 (FIG. 5). A Generate Memory Data Read Cycle command, namely 
1110MD-BE-[Addr] as set forth in Table 1, is first sent to HDT 15. This read command is shifted into register 
300. In so doing, the read opcode resides in opcode portion 305, the BE/MD information resides in BM/MD 
portion 307 and the specified address to be read resides in ADDR/DATA portion 310. 
ta _ ^ Opcode^d^^ communicatee decoded read opcode information (bus - . 



cycle type) to state machine 359. Ah' address' clock pulse is issued to address register 325 to load the address 
* sp^ffied^ 310 into address register 325. State machine. 

. 358 generates standard Ibcal bus control signals to cause the specified local bus operation, here a memory 
.„ read, to \}§£^Qme&J$^ : teta stored at the specified memory address then comes back over the data bus 
<~ . 3^0ffc£^ data. A data-in clock pulse is issued to data-in register 345' 

to cause the return data to be loaded into data-in register 345. 

J. To recapitulated command (opcode) is decoded, state machine 358 generates the cor- 

responding appropriate local bus signals for carrying out that specified type of local bus cycle as set forth in 
the Am486 DX/DX2 Microprocessor Hardware Reference Manual published by Advanced Micro Devices, Rev. 
20 1 , 1993, the disclosure of which is incorporated herein byVsf^p^US^s c : n?:icuiarly.bus cycle state machine 

... 35S of FIG; 5 genera tes-the appropriate standard (Scat "&u^ ^4j&^Si^^^^^S^m^t^^-W^B^B^&^^^^^^ 

D/C#, W/R# t BLAST#, RDY#, BRDY# to initiate a read as per the above manual. 

— It is noted that in one embodiment of the invention, when memoF3M=Bac^aTe-perforrnBd, all fQur&yttwfti&&^z^™ 

are specif iable by the byte enables (BE0-BE3 of the BE/MD field of the command}, are received whether spe^^-* 
25 cified or not by the byte enables. However, when memory writes are performed, the particular byte or bytes 
specified by the BE/MD field are written. 

.^....j!?JP 0ll lJ5!.6 t ® the .memory read, host 200 sends HDT 1 5 a second command, namely a SetectData^^^^ 



MUX 350 to use data-in register 345 as its input. The output of MUX 350 is coupled to the input ofADDR/DATA 



tb^ADDR/DBX^pnbr^ input 
TDI, the return data In ADDR/DATA portion 310 is serially shifted out of register 300 to the TDO output 15A. 
The return data is then communicated over JTAG bus 205 back to host 200. It is noted that if a series of read 
commands are go.ing,.to. be strung together,, then the nert read ^c^ma^djn tt^sen^ wW^^ 



345 will reroato-selec t o d unti l Qthc^ aa J f^tft^edg^^ 



_^:QQS^ input of bus cycle state machine 

*356 so msrtySTAft^ ^ 358. In this manner, state 

the Bus Cycle Type input 

^r^r^^ ^ bus cyde.. 

~ zr ~ - Whfte tR^gcinere^f dfa read memory local Bus i cyde hasloeen^discussed aboveVmany other different 
types of bus cycles can be performed using the described testing technique. Reads/writes (R/W) to memory, 
R/W to peripherals (I/O devices), and also R/W to devices on a PCI expansion bus 55, interrupt acknowledge, 
45 the special bus cycles in Table 3 and other bus cycles can be performed. It is noted that these bus cycles can 
be performed when the system is in either NORMAL or DEBUG mode. When HDT 15 is initiating bus cycles 

f5fT5sf?Tigi5t^ 

or DEBUGSnodi oc 



^^^^^y^^^^^^^^^^^^^^^ IQcat buf cycleirnow discussed for example purposes. To initiate a 
so write memory cycie, host20af irat sends a Write Data Register command (see Table 1 ) to HDT 1 5. Once this 
write commandis shifted into shift register 300, the opcode resides in opcode portion 305 and the data resides 
in ADDR/DATA portion 310. The write opcode within the command is decoded by opcode decoder 357 and 
write data register type information is sent to state machine 358. The Write Data Register command requires 
no action by state machine 358 in terms of gejieratjon of local bua signals. State machine 358 wait s fo^ f ujthe r 
— " sr ' ~ instruction; A^ata-d^ the data in ADDR/DAWpdrtfel^ 

into data-out register 31 57 



*wJj&£econd^^ sent by HDT 15.to complete the desired memory write operatiOT.-Md*&p*fite^ 

ularly, a Generate Memory Data Write command (seeJable/1) is sent toHB^v^Thts writB command includes 
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both a memory data write opcode as well as the address to which the already loaded data is to be written. The 
memory date write opcode is provided to opcode decoder 357 which decodes the opcode and provides memory 
data write type information to state machine 358. An address clock signal is generated by timing and control 
circuit 355 to load the address which is present in ADDR/DATA portion 310 into address register 325. State 
machine 358 generates the appropriate standard local bue signals to cause the specified write memory local 
bus cycle to be performed on local bus 30. When the local bus cycle is completed, the data stored in data-out 
register 315 is stored in memory at the address contained in address register 325. 

It is noted that opcode decoder 357 generates the following clock signals: data-in clock, data-out clock, 
address clock and control reg. clock which are respectively supplied to data-in register 345, data-out register 
315, address register 325 and control registerr320. The data-in clock signal is generated by state machine 358 
and is provided to data-in register 345. In one case, the data-in clock signal pulse is generated after the spe- 
cified read or write bus cycle is performed to load data-in register 345 with the present data on local bus 30. 
The data-out clock signal pulse is generated when a Write Data Register command is decoded by opcode de- 
coder 357 to load data-out register 315 with the present data contents of ADDR/DATA portion 310 of shift reg- 
ister 300: The controtregisterctock signal pulse is generated when opcode decoder 357 decodes a Write Con- 
trol Register command. The address dock signal pulse is generated when opcode decoder decodes one of 
the fast seven commands in Table 1, namely those commands in Table 1A below: 



Table 1A 



20 



25 



10 01MD 
10 10MD 

10 11MD 

11 00MD 
11 01 MD 
11 10MD 



-BE- [Addr] 
-BE- [Addr] 
-BE- [Addr] 
-BE- [Addr] 
-BE- [Addrl 
-BE- [Addr] 



Generate Special Cycle 
Generate I/O Read Cycle 
Generate I/O Write Cycle 
Generate Memory Code Read Cycle 
Rf$erved Cycle^ ^ ; _ . ^ _ 
Generate Memory Data Read Cycle 
Generate Memory Data Write Cycle : 



Bus cycle state machine 358 of control circuit 355 generates bus transactions on local bus 30 as requested 
by the external host 200. Once a particular command is decoded, that is, its opcode is discerned by opcode 

he 



Jypa signal*_sJate machine SSa asserts^^gnaliiDT-HOLD to the arbiter port of integrated processor 10. 
- J? JF^^ 0 ^^ to^feft. bu^^fienaiomdsi (tf Table 1 which result in the generation of the local 




$o the HDT control commands listed below in Table 



45 



50 



55 
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Table 5 



-;4 



20 



HDT CONTROL COMMANDS (CONTROL REGISTER 320 PINOUT) 


. System Control Bus' 22 Bit(s} _ • 


fstame 


Description.(Command Function) - . 1 


9 


CPUCYC 


Execute a CPU single step 


8 


STOPCPU 


Stop the CPU ; 




BESET 


Re&et the System -„ - 




RESCPU 


Reset the CPU 


5 ' — 


ENAPCI 


Enable PC! access to interna! registers^aka. PCIJOEN) i 


r " v . l 


DSPCYC 


Display atFcycfes t)ri the PCI bus (Expansion' Bus 55 is ** t 
a PCI bus in one embodiment.) (aka. BIU_PASS) 


3 *■"' " " : ' 


FLUSH ~" 


Flush the CPU cache (aka. FLUSH#) ' '*"'""* 


2 


DISABLE 


Disable the CPU cache (aka. KEN# to CPU) 






Generate a 


0 ^. 


HDTENA 





25 The MDT control commands are carried out by raising selected bit positions within address/data portion 310 
to a high state. The bit position within address/data portion 310 which is thus raised high causes a respective 
bit position within control register to change state. This change of state of a bit position within control register 



"desired command function. 
-^^—--^For «wmp4e^ should *he werj9f^^ 

'-sends Write^rSr^ R^^ CbntrofcRegistef^ 
command forKESET enoddetfTri the 6ddres£7data portion of the Write Control Register command. The RESET 
command is transmitted over JTAG bus 205 as a bit pattern included within the Write Control Register com- 
mand wherein position 7 of the address/data portion is high. The bit pattern of the command is shifted into 

chine 3§8Jssueis a contcoLre^Sr^i^s^naj jto.iihtrd : r^stfir320^-This causes the bit pattern contained 
■^l*^^^ Iine 7 ( RESET 



^f^B^^^M^^JWt pattern with pos- 
"ifiorfS beingftugh^^ a "generate a 

debug interrupt command" is desired, then a Write Control Register command including a bit pattern with pos- 
ition 1 being high in the address/data portion thereof is transmitted to HDT 1 5, and so forth in a similar manner 
45 with the remaining commands of Table 5. 

In more detail, in the case where the test operator desires to flush the CPU cache (not shown separately, 
but included within CPU 20); a Write Control Register command with the HDTENA and FLUSH bits set (namely 
bits 0 and 3, respectively of the bit pattern) i s sent from host 200 to HDT 1 5 over JTAG bus 205 J n the case 
£5=3=^ HOT^hSfV 



so the corresponding line of system control bus 22 is caused to change state by control register 320. The command 
also includes a set bit at position 3 which initiates the cache flush when the corresponding line of system control 
bus 22 is caused to change state by control register 320. In the present example, the data portion of the com- 
mand includes a bit pattern wherein data bit 0 and 3 are set and the remaining data bits are not set. 

When an HDT command such as the FLUSH command is transmitted within a Write Control Register com- 
— mand to'shtft register 300 of HDT 15, the opcode portion (Write Cdntrol Register) of the Wrife Control Register ~ 
command appears in opcode portion 305 of shift register 300. The data of the Write.Control Register command, ^ 
namely the HpT?Tontror comrnand bit pattern which indicates the FLUSH, appears in data poiton^TprAccitJ^^ 
register clock signal pulse is generated when the Write Control Register command is received and- decoded 
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by HDT 15. The control register clock pulse causes the bit pattern in data portion 310 to be loaded into control 
register 320 and to be supplied to system control bus 22. A FLUSH of the CPU cache thus results when the 
bit pattern of the HDT control command is impressed on system control bus 22 by control register 320. The 
remainder of the control commands of Table 5 are carried out in a similar manner. Whereas the built-in com- 
5. „ mandscdiscussed earlier require no CPU involvement, the HDT control commands of Table 5 do require CPU 
action. 

The manner in which a "snapshot" of selected signals on system control bus 22 is sent back to host 200 
is now discussed. The two input multiplexer 350 provides either return data/result information from data-in reg- 
ister 345 or a read back of the contents of control register 320 with the upper 22 bits cleared to zero in the 

?o ADDR/DATA portion 310. When HDT 15 receives a Select Control Register command from HDT 15, a MUX 
SELECT signal is generated which causes MUX 350 to use the ten (10) lines from control register 320 as its 
input rather than data-in register 345. The read back of the contents of control register 320 reflects the par- 
ticular bit pattern or value loaded therein by the last Write Control Register command. Each bit stored in a bit 
position of control register 320 corresponds to a different system function as per Table 5. Thus, sending these 

is contents of control register 320 back to host 200 via-MUX 350, address/data portion 310 and via JTAG bus 
205 provides a "snapshot" of the system status to the user of host 200. 

It is noted that additional system status information is transmitted back to host 200 each time shift register 
300 transmits its address/data portion 310 contents (bits 0-31) back to host 200. As seen in FIG. 3, the DONE, 
HOLD, INTR. DBGl#, SM!# and INTRJUODE (2 lines) lines are coupled to opcode portion 305 and BE/MD 

20 portion 307. The signal lines are coupled to respective bit positions within shift register 300 according to Table 
5A below: 



25 



Table 5A 



SYSTEM CONTROL STATUS 



Bit(s) 



37 
36 ~ 
35 
34 



33.32- 



45 



50 



0-31 



Name 



HOLD— 

intrT 

DBGI# 
SM1#- 



INTR MODE 




DATA or CONTROL REGISTER CON- 
TENTS , 



Description 



R^ueSi^^us W0e~Cdm0te 
Hold Request Is Pending;, 
Maskable Interrupt Is Pending 
Debug Interrupt Is Pending 
S^^m ^an^Ji^t I nterr4ipt:teP«R^n^rt L . 



Type Of Memory Space Used By Current Memory 
Cycle 

System interrupt mode of the CPU 

00 Normal 

01 System Management Mode 

10 System Debug Mode 

11 System Debug Mode entered from System 
Management Mode. 



Returned result data or control register status. 
(Right justified in 32-bit field. Unused bits are 
zero.) 



55 



When the next command from host 200 is received by HDT 15, the contents stored in ADDR/DATA portion 
310 (whether it be returned data or control register contents) are shifted out to TDO and to host 200 via JTAG 
bus 205. Together with these ADDR/DATA portion 310 contents, the contents of opcode portion 305 and BEVMD 
portion 307 are shifted out to TDO antf to host 200 as well, in this manner, a snapshot of the current state of 
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the 6 system control signals DONE, HOLD, INTR, DBGI#, SMI# and INTRJvlODE is provided to host 200 with 
each transmission of return data. 

Examining these 6 system control bus signals in this manner permits the test operator to determine if a 
system management interrupt is pending (see SMI# in the snapshot), to determine if an interrupt is pending 
^^^.^5 «*j(jiM)tB£tfo Mfcte pending (see HOLD in the snapshot)-,- or to determine the 

current state of the microprocessor, namely, normal or system management mode (see INTR_MODE in the 
snapshot). It is noted that the snapshot can also be examined to determine whether or not a debug interrupt 
is pending (see DBGI# in the snapshot). HDT 15 also drives the MEM_MODE lines in system control bus 22 
to cause each memory cycle to be directed to the appropriate memory space, namely to normal memory space, 
^fiy^mmanagerontn^rTKjry space or sp^ial debug memoryspace. ki other words, the two dedicated 
DE signal lines specify the operating mode of the current memory cycle. 

The symboL# [n ^particular signal indicates that the. subject signal is active low. It is noted that "Data" as 

- set forth at the end of Table 5A refers tathe 32 bits of data captured by HDT 1 5 from local bus 30 in the course 

of testing, . " _ 

refers Td~the ojiroff ^operating. The : 

INTRJvlODE signal may assume four different states or modes, namely, Normal Mode, System Management 
Mode, System Debug Mode and System. Debug Mode entered-from System Management Mode. Normal Mode, 
is defined as the operating state for operating systems and software applications code. System Management 
Mode refers to the operating state provided in the Am486 microprocessor for power management code. System 
20 Debug Mode is the operating state for debug code employed in the present invention. 

external power management controller) that indicates that a system management interrupt is requested. DBGI# 
is the signal to the processor or CPU 20 from the HDT which indicates that a debug interrupt i3 requested. 
~ - ~ - — = INTR is the standard interrupt request signal to the processor. HOLD is the hoW request signal to the processor. 

25 „ . . The above-described system status signals. of Table 5A are captured as a snapshot of the current state 

of the internal signals with the listed names. This "data" (return data or result information) is sent out through 
the TQ.0 lineas new JTAG data is sent into the TDl line to HDT 15 from host 200. It is again noted that the , 



The state diagram for one state machine which may be employed as bus cycle state machine 358 is shown 
"~ ixrzrm FIG,: 8. "State : macftiM'358^ TBLE r ~ 
state, the KOLD ^atef^e HOLDI stet^lhe state, the^YCLE state, thiTTsfete and 

the T2 state. As seen in FIG* 6, the state diagram includes four major sequences, namely generate a bus cycle, 
stop the CPU, single bus cycle step of the CPU and generate a bus cycle from a stopped CPU. 

Bus cycle state machine 358 is reset at power-on to the IDLE state. The state machine is also held in the IDLE 



interface. If a bus cycle wqtte^-»detectedrstate ma<*ine~35fr asserts bus request (the HDT_HOLD signal) 
^— ^nd step&into.the HOLD state. While, in the BOLD:state^Ui^ bu^ Q^3tate.nE^^ samples the bus grant 
^tgnatrnarm^ of local bus 

cycle later and 
£ states. More 



particuiarlyi in the T1 state, address information is propagated to the device (or memory) upon which the re- 
quested bus cycle is to act. In the T2 state, data is propagated to or from the device (or memory) which was 
addressed in the T1 state. The bus cycle which is performed is a conventional bus cycle as described in the 
45 Am486 DX/DX2 Microprocessor Hardware Reference Manual published by Advanced Micro Devices, Rev. 1 , 
1 993, for example in Chapter 7 thereof. More information with respect to the standard T1 and T2 states is pro- 
vided in this Am486 Reference Manual. When the bus cycle is completed as indicated by the RDY or BRDY, 
and B^S^ the IDLE statja.^ 



-..»/> *, , 



T KWfOf f '^SrSM ! SSxsBS i^Wmachrne 358 to Stop CPU execution. This is achieved by requesting Ideal 
so bus 30. When this occurs, CPU bus cycles stop immediately and internal CPU activity stops as soon as the 
CPU requires external data to continue. As seen in FIG. 6, in response to the STOP CPU command the state 
machine asserts the bus request (HDT_HOLD) signal and transitions to the HOLD2 state. The state machine 
waits in the HOLD2 state until bus grant (HDT_HLDA) is detected and then transitions into the HLDA state. 
Thestate machinecan iremain in this HLDA state indefinitely during a debug session. While in this state, state 
"Sf*^13^ bus cycles, allow the CPU to perform single bus cycles, or issue control commands. 

When the STOP CPU request is eventually removed jhe state machine will return to the IDLE state. 
. , Bus-eydes are initiated^ rtHn the KLDA state as justdescribecfc As seea in the state diagram.of FIG. 6, in 
response to a bus cycle request, the state machine transitions to the HOLD1 state and then to the T1 and T2 
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10 



15 



20 



states where the requested bus cycle is performed. The state machine then proceeds back to the HLDA state 
after performance of the requested bus cycle. In this instance, the state machine does not need to acquire 
local bus 30 before the cycle and does not release bus 30 after the cycle. 

CPU 20 is permitted to single step by returning control of bus 30 to CPU 20 for one clock cycle. In response 
-toa Single Step requ«st r the statamadiine drops HDTJIOLD and transitions to the CYCLE state. Since other 
requests may be in the system at this time, the state machine monitors the CPUJHOLD signal (or all of the system 
requests) and waits until CPU_HOLD goes away for one dock cyde. The state machine then asserts HDTJ-IOLD 
and transitions into the HOLD2 state. The state machine then waits in the HOLD2 state until HDT_HLDA is detected 
and then returns to the HLDA state. 

FIG.7 is a representation of the memory space in main memory 125 of FIG. 2. In this particular embodi- 
ment, main memory space spans from zero to 4 Gigabytes. Two reserved memory areas are indicated in FIG. 
7, namely debug memory area 365 and a systems management mode (SMM) memory area 370. The remainder 
of memory 125 is designated as main memory 375. Whereas prior microprocessor memory systems employ 
a reserved SMM area for systems management purposes, such as power saving for example, the present in- 
vention indudes a special debug memory area 365 in addition to the SMM memory area 370. Debug memory 
area 365 is employed to store debug software. In this particular embodiment, both the debug memory area 
365 and the SMM memory area 370 employ 64K reserved memory segments. Other size memory areas may 
be employed as well. 

It is noted that microprocessor 1 0 includes a conventional arbitration circuit or arbiter 400 as shown in FIG. 
8 for determining which particular functional unit is granted access to local bus 30 at any particular time. FIG. 
\£'sl3om-tftffltt^^ CPU 20, alt of which are coupled to local bus 30. 

HDT 1 5, DMA 40, BIU 50 and CPU 20 all contend for local bus 30. When HDT 15 desires access to local bus 
30 as a bus master for that bus, HDT 15 sends an HDTJHOLD signal to arbiter 400. If arbiter 400 determines 
that CPU 20, DMA 40 and BIU 50 do not require access to local bus 30 at this point in time, then CPU 20 sends 
an HDT_HLDA signal (hold acknowledge) signal to HDT 1 5 at the end of the current local bus cycle. In a similar 
manner, CPU 20, DMA 40 and BIU 50 request access to local bus 30 by sending CPUJHOLD, DMAJHOLD 
and BIU JHOLD signals, respectively, to arbiter 400. Arbiter 400 grants access to local bus 30 to CPU 20, DMA 

units. Thus, when state machine 358 asserts HDTJHOLD to arbiter 400, an HDTJHLDA hold acknowledge sig- 
~~-naT^ busns^avaiiabte: — — 

~ *^ state machine 358 asserts signals M/IO#, D/C#, 

W/R#. BLAST#. ADS#, MEMJAODE, ADDR and BE# on local control bus 360 of local bus 30. The particular 
bus transaction (memory read, memory write, I/O read, I/O write, for example) specified by state machine 358 
is carried out. The functional units of integrated processor 10 respond to the assertion of the above signals 
j?M i r ?*?*?*^ toackOP*^ transaction, when sueh wifcf perform 

~ " ^generates a^BRDYtf when it completer a "memory read 



bus transaction. - - r— - - 

— jhffj^^^^g^*^ mflfth m « 358 returns to an idle state awaiting a new 

^ nify the decoding of a new command. In other words, 

iiting to receive another command from host 200 for de- 



25 




45 



coding amf processing; 



In arbitration, whichever master initiates a bus transaction waits for a ready signal from the functional unit 
it is seeking to communicate with. For example, when HDT 15 is attempting to perform a memory read and 
memory controller 35 is ready with the requested data, memory controller 35 sends a RDY# or BRDY# to HDT 
15. HDT 15 then picks up the requested data which is available of local bus 30. 



IV. Hardware/Software Test Tool - Detailed Operation DEBUG MODE 

"""IFone ^ eTfibddmeht of the invention, CPU 20 executes debugging software which is installed in debug 
so memory area 365. For example, a commercially available debugger program such as Turbo Debug from Bor- 
land, Inc. may be employed. More particularly, the debug kernel from such program is stored in debug memory 
area 365 and the user interface portion of the program is stored in host 200. When this debug software in mem- 
ory area 365 is being executed, the system is said to be in debug mode. The debugging software is used for 
debugging applications which run on the target, and can also be used in low level (early development stage) 
55 memory tests, for example. 

Once HDT 15 causes CPU 20 to enter debug mode, the CPU is capable of interpreting debug commands. 
In other words when HDT 15 enters this command interpreting debug mode, the CPU can execute the debug 
commands featured by the particular debugger program. For example, when the Turbo Debug kernel is em- 
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ployed in debug memory area 365 as the debugger program, the CPU can respond to the following debug com- 
mands of Table 6: 



Table 6 
DEBUG COMMANDS 



- read and write a CPU internal register; 

- single step through a program; 
prepare- to execute a program; 

- standard commands; 

other debugger-specific commands. 



20 



25 



These sample debug commands are given by way of example and not by way of limitation. Other debug com- 
mands \a addition to thosa listed above may also be employed* - , - : — 

Initially, the entire debug software program including both the debug kernel and the user interface portion 
is stored in host 200 in a non-volatile storage media. Each time target system 1 00 is turned on and host system 
200 is booted up, the debug kernel is transmitted or downloaded from host 200 oyer JTAG bus 205 to target 
100; When the debug kernel arrives at target TOO; it is stored in special debug memory area 365: The debug" 
kernel which is downloaded into debug memory area 365 includes a command decode and execute section, 
a debug interrupt handler and a breakpoint handler. In this particular embodiment, the entry point for the debug 
"Icernetth memory 365 frGOOFPFO. Oncertoadedin memory area 365; the debug kernel establishes a commu- 
nications protocol with the host from which it is therr capable of receiving debug commands from the debug 
user interface portion on the host. The host communicates with the target system's debug kernel by using ar- 
bitrarily chosen, but specif icm^mqr^J<^ 

ass= ^Hste£mfe^ 



memory area. The host then obtains Jhe result or_responsjye in form ation from Lhe debug kernel by reading^ 
~ - comthu rftc^tidh between: tft a debug kernQof &rqet 1 00 is over JTAG 

„ ^j^2Q5*Yhelabove arrangement of debug memory space.365 permits host 200 to send commands to HDT 
15 and receive results from HDT 15 without being intrusive on normal microprocessor operations since both 
the commands and results are stored outside of normal main memory space. 
w YVhenCPU 20 is executing debug code in debug memory area 365, it is said to be in the debug mode. In 



45 



rccmdftlDri^ iffoenfircieSug mode; it saves the 

contents of the CPU" registers to main memory 125'for later recall. The CPU then looks to the debug memory 
segm$flt365~and exaeuto-ift^^ debug kernel is 

'^et^g to resume 

"^"^^^ SS^^ executed 
bythir&T^ such software applications. 

These functions are available in the debug kernel. Results from these operations, if any, are stored in the de- 
bug memory segment 365 for later retrieval by host 200. 

The first way for the CPU to enter the debug mode is for HDT 1 5 to receive a specific command from host 
200 which instructs HDT 15 to generate a debug interrupt. More specifically, host 200 sends HDT 15 a Write 
Control Register command including a HDT control command (DBGINTR, see Table 5) which forces HDT 15 
and CPU 20 into the debug mode. A debug interrupt is thus said to be issued which causes the CPU to enter 
the debug^mpde. In ihiscase, JtojCPjyjia§ entered jfebyg,^ 
upon encountering a predetermined condition. 

Asecond way that debug mode can be entered is via address matching. As seen in FIG. 1 , CPU 20 includes 
four debug registers, namely registers DR1, DR2, DR3 and DR4. Selected addresses of interest to the test 
operator are stored In these debug registers. If the address of the current line of code which is presently being 
executed matches the contents of any of the four debug registers DR1 , DR2, DR3 and DR4, then debug mode 
is enteredj>y thajSPJU. ^^^f^B^^s^ 

A third way for CPU 20 to enter the debug mode is for CPU 20 to encounter a debug instruction in the 
course of normal execution of an application. For example, this would occur wttfe?r# debug instruction is in- 
serted in an application program by debugger software such as Turbo Debug by Boiland, Inc. Microprocessors 



50 
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such as the Am486 are programmed to recognize the debug instruction and to enter a debug state when such 
an instruction is encountered. 

As a prelude to discussing the flow diagram of FIG. 9A-9B, it is noted that there are two ways for commands 
to be carried out by HDT 1 5. These two ways correspond to the two different types of commands, namely debug 
5. commands as defined in Table 6. and so-called built-in commands/control commands as defined in Tables 1 
and 5. 

With respect to debug commands which are carried out in debug mode, host 200 communicates with the 
target computer's debug kernel which is stored at a predetermined memory location in the debug memory seg- 
ment or debug memory space 365. The host writes a debug command via JTAG bus 205 to this debug memory 

10 space. Once a debug command has been so written to the debug space, it is available for processing by the 
target CPU. The debug kernel carries out the particular command and stores responsive information, namely 
the result, in the debug memory space for later retrieval by the host computer. To retrieve this result information , 
the host computer reads the result from the debug space via the JTAG bus. The host computer thus receives 
result information back from the debug kernel. 

is With respect to built-in* commands, namely those which Initiate bus cycles and related activities set forth 
in Table 1 , these commands can be carried out in either normal mode or debug mode. Likewise, the HDT control 
commands listed in Table 5 can be carried out in either normal mode or debug mode. Normal mode refers to 
those times when target computer 1 00 is not in debug mode. Typically, normal mode includes those times when 
target computer 100 is executing an application program or is idle. 

20 

V. Operational Flow 




FIG. 9A and FIG. 9B together form a flow diagram depicting the operational flow of the system which in- 
cludes target computer 100 and host computer 200. For clarity, FIG. 9A is directed mainly to HDT operations 
25 wherein HDT 15 receives commands from the host 200 and so-called "primitive" operations, such as reads 
and writes, are performed by the HDT on the local bus. FIG. 9B is directed mainly to those system operations 
wherein CPU 20 is called upon to execute the debug kernel which is stored in debug memory segment 365 
-aM^frerSTtfft^^^ as mbdifying'iftiOTh registers, for ex- 

ample. 

3(r- Referring nowto ^RGr/aArlfT^assumed that target computer 100 is initialized and is operating in the normal 
mode Tn'BFdck 500. In normal m6de, CPU 20 is typically executing application software or is idle. An HDT R/W 
command (read/write command), an HDT control command or an HDT debug interrupt is issued or occurs at 
block 505. Atest is then conducted at decision block 510 to determine if HDT 1 5 has issued an R/W command 
(read/write command) or an HDT control command. 

3* . ; . Jfan^Fb^cgm^ at block 510, then such command is decoded at 

" block 512 to determine which" particular R/W command has Been received. State machine 358 then requests 
a bus cycle by issuing the appropriate bus cycle control signals on local control bus 360 to cause the local bus 
Jrans^ be initiated on local bus 30 as per block 514. A test is 

^ Pfffd^rW^SKTIiiSivailable to carry out the particular bus cycle specified 

is not available, then HDT 15 waits until bus 30 is available. 
When local bus 30 becomes available, then the specified bus cycle is performed as per block 520. A DONE 
signal is then generated when the bus cycle has been performed to signify that the bus cycle is complete. If 
the specified local bus operation is one where data is returned, as for example in the case of a memory read, 
then such data is returned to host 200 over JTAG bus 205 in block 530. For this data return to occur, MUX 
45 350 is switched to couple data-in register 345 to the address/data portion 310 of shift register as per MUX select 
block 527. The system control status signals, DONE, HOLD. INTR, DBGI#, SMI# and INTRJvlODE are re- 
turned as well to host 200 at block 535 along with the return data. Process flow then continues back to block 
500 with target 100 being in the normal mode. 

If a determination was made at decision block 510 that an HDT control command is present, then as per 
so block 540 the bit pattern of the HDT control command is loaded into control register 320 and is placed onto 
control bus 22 to initiate the function specified in the control command. The function specified in the control 
command is performed at block 545. A snapshot of the control register 320 lines is returned to host 200 at 
block 550. In more detail, when a Select Control Register command is received by HDT 15, the MUX select 
signal provided to MUX 350 causes the control register 320 output to be coupled through to address/data por- 
55 tion 310 of shift register 300 as per MUX select block 547. In this manner, the control register line snapshot 
is returned to host 200 at block 550. At the same time that the control register line snapshot is returned, the 
system control status signals DONE, HOLD, INTR, DBGI#, SMI# and INTRJYIODE are returned as well to host 
200 at block 555. Process flow then continues back to block 500 with target 100 being in the normal mode. 
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While not shown graphically in the flowchart of FIG. 9A, it is noted that whenever microprocessor 10 is in 
normal mode as in FIG. 9A, microprocessor 10 still continually checks to see if a debug interrupt condition 
exists as indicated in FIG. 9B. More particularly, the presence of four conditions is tested at decision blocks 
561, 562, 563 and 564. Decision block 561 checks to see if a debug interrupt command OBGI has been issued 
by ho8k2^to:mteB^ 

mode. A test i"s~alSo made at decision block 562 to determine if the instruction presently being executed is a 
breakpoint and if so, microprocessor 10 enters debug mode. Moreover, a test is performed at decision block 
563 to determine if the address of the instruction currently being executed matches the contents of any one 
of the four debug registers DR1 . DR2, DR3 and DR4. If such a match occurs, debug mode is entered. Another 
test js conducted at de<cj?joa block 564 to determine if the instruction currently being executed by the micro* 
processor is a debug instruction, and if so, debug mode is entered. 

More specif icaily,. if any of tests 561-564 are answered in the affirmative, the processor saves the contents 
of its internal registers to main memory at block 565 and enters debug mode. The debug kernel which is stored 
in the. special memory segment 365 is then entered and executed at block 570 as the processor enters debug 

A test is then conducted at decision block 575 to determine if a host debug command is available. In other 
words, HDT 15 looks to see if any Table 6 debug command* have, been received from host 200. A floating 
block 580 is used to indicate that the processor is continually looking to see if HDT 15 has sent a command 
to debug memory space. Once a host command appears, the host command is performed or executed at block 
585 and simultaneously therewith the host ready status is prepared at block 590. That is, if host 200 is ready 
to send another command to HDT 1 5, it so indicates by sending an appropriate host ready status signal to HDT 
15 over JTAG bus 205. The next debug command is then sent to HDT 15 and is then performed by HDT 15. 
Results, if any, from CPU 20 and associated devices in response to debug commands are stored in debug 
memory segment 365 as per block 595. Host 20C retrieves these- results- usingth* JTAG bu9 205. When host" 
200 is donesending debug commands to HOT 1 5 T host 200 sends an exit command to HDT 1 5. A test is con- 
ducted at decision block 600 to determine if it is appropriate to exit the debug mode. If an exit command is not 
detected at decision block 600, then process flow continues back to the host command available block where_ 



then the internal registers of CPU 20 are restored at block 605 and processflowjrontinues back to block 610 
atnvrteh*HBT~t5r^^ mode 

tfWtfgff^ block 610, the processor can 

be placed in system management mode (block 615) by issuing a system management interrupt thereto. Once 
back in normal mode, the processor continues to check for the presence of any R/ W commands or HDT control 
commands (block 510) as in the flow diagram of FIG. 10A and also continues to check for the presence of any 
3^ z tfthffft^ _ — — 

~ ^- ^ on tne lerrmost path inlfie 

flow diagram of FIG. 9 A are advantageously performed without CPU involvement This is especially beneficial 
In trteearly.stages.of system. ^ of the target 

frWrtrY the flow 



20 



25 



— computerrmry-notbg y g WSt aigCre tFg 




actually executed 

by CPU 20 and results are passed back to host computer 200 via the debug memory space 365. The built-in 
commands are used to pass the debug commands to the CPU. 



VI. Bus Structures And HDT Pinouts 

45 

Returning momentarily to the case where one of the built-in commands of Table 1 is being executed by 
HDT 1 5. it will be recalled that the bus cycle specified in the command is carried out and that a result is returned 
over local bus 30. In the case of a read, the data that is read from memory is returned as a result, In addition, 
a snapshot of local bus 30 is returned to host computer 20. This snapshot includes a JTAG Status Return which 
so is defined as information with respect to the current state of the first six internal system control bus signals 
given above in Table 5A(ie. bits 32-38) and the contents of control register 320 (stored in shift register locations 
0-21 with unused locations being zeroed.) 

FIG. 10 is a diagram showing the pin-out of HDT 15 including the JTAG serial interface or port 15A, local 
bus interface 30A, the remaining,pins of HDT JSJttyngJhe control interface thereof, namely system control 
55 bus 22. ' " " 

The pin-cut of JTA^tnterf ace 1 5A is conventional and is represented^ the following pins : erf HDT-1 15 » given 
in Table 8. ~ ~ 
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Table 8 



10 



15 



JTAG INTERFACE 


Pin Name 


Function 


CLOCKHDT 


:IN; Clock Phase 1 


CLOCKHDTF 


:IN; - Clock Phase 2 


SHIFTHDT 


:IN; Shift/Load control 


UPDATEHDT 


:IN; - Copy shift register to destination 


HDTTDI 


:IN; - Input serial data 


HDT.TDO 


:OUT; - Output serial data 



20 



The Local Bus interface 30A is represented by the following- pins of HDT 15 given in Table 9. As discussed 
earlier, local bus 30 couples CPU 20 to HDT 15 and other system components as shown in FIG. 1. Local bus 
30 includes the following lines listed in Table 9. It is noted that CPU 20 and HDT 15 each include pins having 
labels corresponding to the following lines of local bus 30 set forth in Table 9. 

Table 9 



25 



35 



LOCAL BUS PINOUT 



Pin Name 



45 



50 



SYSCLK 
SYSCLKP1 
SYSCLKP2 - 
SYS.RESET 
A31:A0 
:B3t:-DKr:.^7.: 
jBE3#:BE0# 

D/C# 
W/R# 
ADS# 
EADS# 
BLAST# 
RDY# 
BRDY# 
KEN# 
FLUSH* 



55 



Function 



IN; System clock 
IN; Clock phase 1 



UN; Cfock;pta8e>2— — 
IN; - Synchronous system reset 
OUT; - Memory or I/O addresses 
JW€^> Memory or I/O data 
OUT -- Byte enables 

Memory (high) or I/O 
OUT -- Data (high) or Code (low) 
OUT Write (high) or Read (low) 
OUT Address Strobe 
OUT Cache Invalidate Address Strobe 
OUT -- Last cycle of burst (low). 
IN - Responder Ready, Single Cycle 
IN - Responder Ready, Burst Cycle 
OUT - CPU Cache Enable 
OUT ~ Flush CPU Cache 



The pins and lines listed above for local bus 30 from A31:A0 through FLUSH# are standard to the Am486 mi- 
croprocessor which-ie manufactured by Advanced Micro Devices, Inc. and described in the Am486 DX/DX2 
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Microprocessor Hardware Reference Manual, Rev. 1, 1993 published by Advanced Micro Devices, Inc. The 
signals SYSCLK, SYSCLK1 and SYSCLK2 are clocking signals which are supplied to HDT 15 to provide clock- 
ing to the components thereof. 

System control bus 22 couples CPU 20 to HDT 15 as set forth in the pinout listed in Table 10. It will be 
. recalled that control -register 320 drives these system control bus lines and that a snapshot of these lines with- 
out the MEM_MODE signal is provided back to host 300 through the cooperation of MUX 350, address/data 
portion 310 of shift register 300 and JTAG bus 205. 

Table 10 



10 


r " — ~ ' SYSTEM CONTROL BUS 




Pin Name 


Function 


15 


nuLU 


*IN « Sv^tem wide Hold Rflfiue^t 


INTR 


:IN - Interrupt Request 




DBGI# 


:OUT - DBI Request 


20 


SMI# 


- SMI Request 


INTR_MODE 


:IN Operating Mode of the CPU (2 bit signal) 




MEM_MODE 


:IN « Operating Mode of the current memory cycle from CPU (2 bit signal) 


25 


BR^PASS — ~ 


:OUT —Instruct BHJ to pass aH cycles to the PCI'&us (expansion busf " v u 


PCIJOEN 


:OUT - Instruct BIU to respond to I/O requests from external initiators 




JS^FSFT „ 






RESET 


:OUT - Reset CPU 



The following two signals relate to the control of local bus arbitration, but are grouped separately from system 
control bus 22. 



35-- 




HDTJ-IOLD 


OUT » HDT Hold Request 






^HUt.HLUA " 
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It is noted that CPU 20 andHQE^eaciUn^^ following-control 

_ — 



lines of system 
W 



ffftre m?mf&Wl!rfeffitf\48& micropro- 
cessor which is manufactured by Advanced Micro Devices, Inc.(AMD) and which is described in the AMD pub- 
lication Am486 DX/DX2 Microprocessor Hardware Reference Manual, Rev. 1, 1993. 

FIG. 11A-11E shows a series of timing diagrams illustrating the signals on local bus 30 while HDT 15 is 
being operated. More particularly, FIG. 11A shows local bus signals when HDT 15 is performing a memory 
read bus cycle in normal mode. FIG. 11 B shows local bus signals when HDT 15 is performing an I/O read bus 
cycle during normal mode. FIG. 11 C shows local bus signals when HDT 15 is performing a memory write bus 
cycle during normal mode. FIG. 11 D shows local bus signals when HDT 15 is performing a memory write in 
system debug mode. FIG. 11E show local bus signals when HDT 15 is performing a data write in SMM, system 
management mode. 

While the above description sets forth an integrated processor apparatus with on-board testing capability, 
it is clear that a method of testing the integrated processor and associated devices is also disclosed. More par- 
ticularly, a method is provided for testing an integrated processor which includes a die on which a CPU and 
at least one functional unit are situated. The CPU and functional unit are coupled together by a local bus. The 
method includes the step of providing the processor with a testing circuit which is situated on the die and which 
is coupled to the local bus. Thrmethod also includes the step of sending a test command to the testing circuit 
from a host computer external to the integrated processor. The method further includes the step of receiving 
the test command by the testing circuit thus resulting in a received test command. The method still further in- 
cludes the step of generating a local bus cycle, by the testing circuit, in response to the received test command 
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to provide testing of the processor and devices coupled thereto. 

The foregoing has described an integrated microprocessor including a built-in testing capability. The inte- 
grated microprocessor test system is capable of testing the components of an integrated microprocessor and 
devices coupled thereto. Advantageously, the test system provides such testing throughout the multiple stages 
5 of microprocessor computer system development, that is, from prior to achievement of system booting all the 
way through operating system load and application software development 

While only certain preferred features of the invention have been shown by way of illustration, many mod- 
ifications and changes will occur. It is, therefore, to be understood that the present claims are intended to cover 
all such modifications and changes which fall within the true spirit of the invention, 

10 

Claims 

1. An integrated microprocessor comprising: 
is a semiconductor die; 

a central processing unit situated on said die; 

a local bus situated on said die and coupled to said central processing unit; 
at least one functional unit situated on said die and coupled to said local bus; and 
a testing circuit, situated on said die and coupled to said local bus, for initiating a local bus cycle for 
20 testing purposes in response to a test command originating external to said microprocessor. 

2. The integrated microprocessor of claim 1 wherein said testing circuit further includes decoding means 
for decoding a type of bus cycle set forth in said command. 

3. The integrated microprocessor of claim 2 wherein said testing circuit further includes a bus cycle state 
machine for generating the type of bus cycle indicated by said command. 

25 4. An integrated microprocessor comprising: 

a semiconductor die; 

a central processing unit situated on said die; 
r^r-^^^^y^ processing unit; 

at least one functional unit situated on said die and coupled to said local bus; 
3£r ~ ~ la mem^ including a debug memory space for storing debug 

sdftwareTand' ' "* 

testing means, situated on said die and coupled to said local bus, said testing means being operative 
in a bus cycle mode for initiating local bus cycles to test said microprocessor and functional units coupled there- 
to in response to test commands originating external to said microprocessor, said testing means being oper- 
35 atrve in a debug mode for executing said debug software which is stored in said debug memory space. 

5, The integrated*mlcroprotess©r'Cf claim 4wherein said testing means further includes decoding means 
for decoding a type of bus cycle set forth in said command. 
_ _ .„ 6,/Thejntegrated microprocessor of claim 4 wherein said testing means includes debug mode command 
B ~*f^^^ receives a test command including a debug mode 

7. The integrated microprocessor of claim 4 further comprising: 

at least one debug register situated in said central processing unit, 

said microprocessor including address matching means for determining when a match occurs between 
an address stored in said debug register and an address of an instruction which is currently being executed, 
45 said microprocessor entering said debug mode when said match occurs. 

8. The integrated microprocessor of claim 4 further comprising: 

debug instruction sensing means, situated in said central processing unit, for detecting when a currently 
executed instruction is a debug instruction such that said microprocessor enters said debug mode when said 
debug instruction is detected. 
so 9. A computer development system comprising: 

a target computer including an integrated microprocessor having 
a semiconductor die; 

a central processing unit situated on said die; 

a local bus situated on said die and coupled to said central processing unit; 
55 at least one functional unit situated on said die and coupled to said local bus, 

a peripheral device coupled to said local bus; : 

a memory coupled to said central processing unit and including a debug memory space for storing 
debug software; 
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testing means, situated on said die, and coupled to said focal bus, said testing means being op- 
erative in a bus cycle mode for generating local bus cycles in response to test commands originating external 
to said microprocessor, said testing means being operative in a debug mode for executing said debug software 
which is stored in said debug memory space, and 
5 . a host computer, coupled to said target computer, for providing said testing means with test commands 

and for retrieving the results of said test commands from said target computer. 

10. The integrated microprocessor of claim 9 wherein said testing means further includes decoding means 
for decoding a type of bus cycle set forth in said command. 

11. The integrated microprocessor of claim 9 wherein said testing means includes debug mode command 
10 detecting, means for detecting, when said microprocessor receives a test command from said host computer 

including a debug mode request. 

12 The integrated microprocessor of claim 9 further comprising: 
at least one debug register situated in said central processing unit, 

said microprocessor including address matching means for determining when a match occurs between 
is an address stored in said debug register and an address of an instruction which is currently being executed, 
said microprocessor entering said debug mode when said match occurs. 

13. The integrated microprocessor of claim 9 further comprising: 

debug instruction sensing means, situated in said central processing unit, for detecting when a currently 
executed instruction is a debug instruction such that said microprocessor enters said debug mode when said 
20 debug instruction is detected. 

14. The integrated microprocessor of claim 9 further comprising a test bus coupling said host computer to 
said testing means of said target computer. 

15. The integrated microprocessor of claim 14 wherein said test bus comprises a JTAG bus. 

16. A method of testing an integrated processor, said processor including a die on which a CPU and at 
25 least one functional unit are situated and coupled together by a local bus, said method comprising the steps 

of: 

providing said processor with a testing circuit coupled to said local bus and situated on said die; 

If ¥i§Sf5 Sr r^ ^ proces^* 
sor; 

r^efvingsaltf t^ 

^"^gerieratfhg a focal bus : cycle, by said testing circuit, in response to said received test command to provide 
testing of said processor and devices coupled thereto. 

17. The method of claim 1 6 further comprising the step of: 

decoding the received test command to determine the particular type of local bus cycle specified by 
35 said received test conroand^w^ ^r^ _ ^ , , _ 



Ta.Tfie^ havlrlga "memory coupled" 

thereto wherein 

said sending stepJn&udea sendtfngjMneroo^ and 
thereto wherein 

said sending step includes sending a memory read request command to said testing circuit, and 
said generating a local bus cycle step includes generating a memory read bus cycle to test said memory. 

20. The method of claim 16 wherein said functional unit is a bus interface unit having an I/O device coupled 
45 thereto wherein 

said sending step includes sending an I/O write request command to said testing circuit and 

said generating a local bus cycle step includes generating an I/O write bus cycle to test said I/O device. 

21 . The method of claim 1 6 wherein said functional unit is a bus interface unit having an I/O device coupled 
thereto wherein 

so said sending step includes sending an I/O read request command to said testing circuit, and 

said generating a local bus cycle step includes generating an I/O read bus cycle to test said I/O device. 

22. A method of testing an integrated processor, said processor including a die on which a CPU and at 
least one functional unit are situated and coupled together by a local bus, said method comprising the steps 
of: 

55 storing debug software in a debug memory space in a memory coupled to said processor 

providing said processor with a testing circuit coupled to said local bus and situated on said die; 
sending a test command to said testing circuit from a host computer external to said integrated proces- 
sor; 
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receiving said test command by said testing circuit thus resulting in a received test command, and 
generating a local bus cycle, by said testing circuit, in response to said received test commands to pro- 
vide testing of said processor and devices coupled thereto. 

23. The method of claim 22 further comprising the step of: 

executing said debug software which is stored in said debug memory space thus causing said processor 
to operate in a debug mode. 

24. The method of claim 23 including the step of detecting when said microprocessor receives a test com- 
mand from said host computer including a debug mode request, thus causing said processor to enter said de- 
bug mode. 

25. The method of claim 23 wherein said processor includes at least one debug register, said method fur- 
ther comprising the step of determining when a match occurs between an address stored in said debug register 
and an address of an instruction which is currently being executed, said microprocessor entering said debug 
mode when said match occurs. 

26. The method of claim 23 including the step of detecting when a currently executed instruction is a debug 
instruction such that said microprocessor enters said debug mode when said debug instruction is detected. 
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